iT邦幫忙

2024 iThome 鐵人賽

DAY 27
0
Security

資安這條路:系統化學習網站安全與網站滲透測試系列 第 27

資安這條路:Day 27 SSDLC 安全開發軟體生命週期─設計階段與威脅建模

  • 分享至 

  • xImage
  •  

前言

上一篇提到 SSDLC 中的需求階段,而本篇注重在設計階段中的,並且提及常見的威脅建模方法。

SAMM 設計階段的措施

  1. 威脅評估
  2. 資安要求
  3. 資安架構

威脅評估

威脅評估就像是在軟體開發過程中進行「資安健檢」,找出潛在的弱點並評估可能造成的危害

  1. 應用程式風險設定檔
    • 建立應用程式風險設定檔,就像幫每個軟體建立「病歷」,記錄它的健康狀況
      • 首先要列出組織內的所有應用程式,評估每個應用程式的重要性,以及它處理的資料有多敏感
      • 例如,線上銀行系統處理的是高度敏感的金融資料,風險等級就高於內部員工通訊錄
    • 找出高風險應用程式,就像找出哪些軟體「體弱多病」,需要特別關注
      • 因為這些應用程式一旦被攻擊,對組織的損失會更大
  2. 威脅建模
    • 執行威脅建模,就像請「資安專家」模擬攻擊軟體的各種方式
      • 資安專家會找出軟體中有哪些弱點,攻擊者可能如何利用這些弱點,並提出相應的防禦措施
    • 使用 STRIDE 威脅清單,就像資安專家手中的「放大鏡」,可以更全面地找出各種威脅
      • STRIDE 包含六種常見的威脅類型
        • Spoofing 身份假冒:攻擊者偽裝成合法使用者,例如盜用帳號密碼
        • Tampering 資料竄改:攻擊者修改資料,例如竄改交易金額
        • Repudiation 抵賴:攻擊者隱藏自己的行為,例如刪除操作日誌
        • Information Disclosure 資訊洩漏:攻擊者竊取敏感資訊,例如客戶的個資
        • Denial of Service 服務阻斷:攻擊者讓系統無法正常執行,例如發動大量流量攻擊
        • Elevation of Privilege 權限提升:攻擊者取得更高的權限,例如從普通使用者變成管理員

資安要求

資安要求就像在軟體開發過程中制定「資安守則」
確保軟體符合一定的資安標準

  1. 軟體需求
    • 明確考慮資安性需求
      • 就像在「資安守則」中明確規定「門窗要上鎖」
      • 如要求在傳輸和儲存個人資料時都要加密,就像幫資料加上「防盜鎖」
    • 從攻擊者的角度審查功能
      • 就像「資安專家」會假扮成小偷,檢查房子有哪些地方容易被入侵
      • 例如,檢查使用者註冊功能是否容易被機器人程式濫用
    • 建立資安性需求框架
      • 就像把「資安守則」整理成一本手冊
      • 方便開發團隊參考
  2. 供應商資安性
    • 對軟體開發中涉及的外部供應商資安能力和習慣進行供應商評估
      • 就像在選擇合作夥伴時,要先了解他們的資安名聲
      • 例如,使用問卷調查或訪談來了解供應商的資安措施是否到位
    • 要跟供應商明確討論組織對於資安期望
      • 就像在簽合約之前,要先講清楚彼此對資安的責任
    • 要確保供應商了解並符合組織的風險偏好
      • 就像要確認合作夥伴的資安標準和你的組織一致

資安架構

資安架構就像軟體的「資安藍圖」
用來規劃和管理軟體的資安設計和實作

  1. 架構設計
    • 在軟體設計過程中納入主動式資安性指南的考慮
      • 就像在設計房屋時,要考慮防盜、防火等資安因素
      • 例如,採用多層次防禦策略,就像在房屋周圍設置圍牆、警報器和監視器
    • 審查設計中使用的資安功能、資安故障、資安性和可用性的平衡、以最低權限執行、避免資安性通過隱藏等原則
      • 就像檢查「資安藍圖」是否合理,是否有漏洞
    • 識別具有資安功能的共享基礎設施或服務
      • 就像選擇可靠的保全公司和設備
      • 例如,使用單一登入服務、存取控制服務和日誌記錄服務
    • 建立一組代表實施資安功能的合理方法的實作方法
      • 就像制定一套標準的保全操作流程
    • 建立參考架構,選擇並組合一組經過驗證的資安元件,以確保正確設計資安性
      • 就像參考其他成功的資安設計案例
  2. 技術管理
    • 在開發、部署和操作過程中評估所用重要技術(例如開發堆疊和工具、部署工具以及作業系統和工具)的資安品質
      • 就像定期檢查保全設備是否正常執行
    • 識別組織中軟體專案中常用的技術、框架和工具
      • 就像了解市面上有哪些主流的保全技術
    • 建立一份建議技術清單,並在整個開發組織中分享
      • 就像推薦給其他部門使用可靠的保全設備
    • 所有專有開發(內部或收購),強制並監控標準化技術的使用
      • 就像規定所有部門都要使用統一的保全系統

OSTG 中設計階段的資安措施

1. 檢查資安需求 (Review Security Requirements)

  • 想像一下,你正在蓋房子,資安需求就像房子的藍圖
    • 在這個階段,需要仔細檢查藍圖,確保每個細節都清楚且完整
  • 例如,藍圖上寫著「房子要有門禁」,但沒有說明是密碼鎖還是傳統鑰匙
    • 這時就需要和設計師確認清楚,避免後續施工出現問題
  • 在檢查資安需求時,你需要考慮以下幾個方面:
    • 使用者管理: 哪些人可以進出這棟房子?
    • 身分驗證: 如何確認進出的人是誰?
    • 授權: 哪些人可以進入哪些房間?
    • 資料機密性: 如何保護房子裡的秘密文件?
    • 完整性: 如何確保房子結構的穩固?
    • 責任追究: 如果發生問題,如何找到負責人?
    • 工作階段管理: 訪客進出房子的時間如何管理?
    • 傳輸資安: 如何確保房子與外界通訊的資安?
    • 分層系統隔離: 如何將房子分成不同的區域,限制不同人的進出?
    • 法規與標準遵循: 房子需要符合哪些建築法規和資安標準?

2. 檢查設計和架構 (Review Design and Architecture)

  • 繼續以蓋房子為例,設計和架構就像房子的設計圖
    • 需要檢查設計圖,確保它符合資安需求,也就是藍圖上的要求
  • 在設計階段發現問題,就像在施工前修改設計圖一樣,成本低且容易修改
  • 例如,設計圖上將門禁控制分散在多個地方,可能會增加管理的複雜度
    • 這時可以考慮設計一個中央門禁系統,方便管理所有門禁
  • 如果發現任何設計上的缺陷,應該與建築師討論,找出替代方案

3. 建立和審查 UML 模型 (Create and Review UML Models)

  • UML 模型就像房子的 3D 模型,可以更直觀地展示房子的結構和執行方式
  • 透過 UML 模型,可以與設計師確認彼此對房子設計的理解是否一致
    • 例如,模型可以顯示每個房間的大小、門窗的位置、電路的走向等
  • 如果在模型中發現任何問題,也需要與設計師討論,找出解決方案

4. 建立和審查威脅模型 (Create and Review Threat Models)

  • 威脅模型就像對房子進行資安評估,找出潛在的資安風險
    • 需要模擬各種可能的威脅情境,例如小偷、火災、地震等等,並分析房子如何抵禦這些威脅
  • 例如,需要確認門窗是否堅固、是否有安裝警報系統、逃生路線是否暢通等等
  • 如果發現房子無法抵禦某些威脅,就需要和設計師重新檢視設計,進行必要的修改

應用程式風險設定檔

定義

應用程式風險設定檔是一個文件
用於識別和評估特定應用程式可能面臨的資安風險

此設定檔旨在幫助組織
了解哪些應用程式在受到攻擊或入侵時可能對組織構成嚴重威脅
以便優先處理資安工作並分配資源

目標

  • 識別組織中的所有應用程式
  • 評估每個應用程式的風險,考慮因素例如資料敏感性、使用者群、攻擊面和環境
  • 根據風險等級(例如高、中、低)對應用程式進行分類
  • 為每個風險等級提供詳細說明
  • 提出降低每個風險的建議措施,例如資安控制、測試和監控

優點

  • 協助組織優先處理資安工作並將資源分配給最關鍵的應用程式
  • 提供對組織資安狀態的全面了解
  • 協助威脅建模和資安需求定義
  • 協助組織遵守資安法規和標準

元素

  • 應用程式名稱和描述:提供應用程式及其功能的清晰識別
  • 風險等級:應用程式面臨的整體風險等級,通常分為高、中、低
  • 風險等級說明:詳細說明風險等級,包括影響評估的特定因素,例如處理的資料類型、使用者群、攻擊面和環境
  • 建議措施:提出減輕已識別風險的步驟,例如實施多重要素驗證、進行資安測試或監控可疑活動

步驟

步驟 1:識別應用程式

識別組織內的所有應用程式
可能包括網路應用程式、行動應用程式、桌面應用程式和後端系統

步驟 2:評估每個應用程式的風險

識別所有應用程式後
需要評估每個應用程式的風險
這可以使用各種因素來完成

  • 應用程式處理的資料類型:某些資料(例如個人資訊或財務資料)比其他資料更敏感
  • 應用程式的使用者群:具有大量使用者或具有高權限使用者的應用程式比具有少量使用者或具有低權限使用者的應用程式風險更大
  • 應用程式的攻擊面:具有較大攻擊面的應用程式(例如具有許多功能或與許多其他系統整合的應用程式)比具有較小攻擊面的應用程式風險更大
  • 應用程式所處的環境:在具有高度敵對性環境(例如網際網路)中執行的應用程式比在具有較低敵對性環境(例如封閉式內部網路)中執行的應用程式風險更大

▲ 有一些企業會以為內部網路絕對,這是錯誤的概念,近年來許多駭客都是進入內部網路之後,沒有做好網段隔離導致影響非常大

步驟 3:建立風險設定檔

評估每個應用程式的風險後,
可以建立風險設定檔風險設定檔應包含以下資訊:

  • 應用程式名稱
  • 應用程式描述
  • 應用程式的風險等級(例如高、中、低)
  • 每個風險等級的說明
  • 減輕每個風險的建議措施

步驟 4:審查和更新風險設定檔

  1. 應該定期審查和更新應用程式風險設定檔,以確保它們仍然準確
  2. 當組織發生變化或發現新的威脅時,應進行審查

範例

  • 應用程式 A

    • 名稱:線上銀行應用程式
    • 說明:允許客戶線上存取其銀行帳戶的網路應用程式
    • 風險等級:高
    • 風險等級說明:此應用程式處理高度敏感的財務資料,並可供大量使用者使用
    • 建議措施:實施多重要素驗證、定期進行資安測試和監控應用程式是否有可疑活動
  • 應用程式 B

    • 名稱:員工入口網站
    • 說明:允許員工存取公司資訊和資源的網路應用程式
    • 風險等級:中
    • 風險等級說明:此應用程式處理一些敏感資料,但它不像線上銀行應用程式那麼敏感
    • 建議措施:實施強式密碼原則、定期進行資安培訓,並監控應用程式是否有可疑活動
  • 應用程式 C

    • 名稱:行銷網站
    • 說明:提供有關公司產品和服務資訊的公開網站
    • 風險等級:低
    • 風險等級說明:此應用程式不處理敏感資料
    • 建議措施:實施基本資安措施,例如防火牆和防毒軟體
欄位 說明 範例
應用程式名稱 應用程式的名稱 線上銀行應用程式
應用程式描述 應用程式功能的簡要描述 允許客戶線上存取其銀行帳戶的網路應用程式
風險等級 應用程式的整體風險等級(例如高、中、低)
風險等級說明 風險等級的詳細說明,包括支援風險評估的因素 此應用程式處理高度敏感的財務資料,並可供大量使用者使用
處理的資料類型 應用程式處理的資料類型,包括其敏感性分類 個人資訊、財務資料
使用者群 應用程式的目標使用者,包括其規模和權限級別 註冊客戶、銀行員工
攻擊面 應用程式暴露於潛在攻擊的程度,考慮其功能和整合點 網路介面、行動 API、後端資料庫
環境 應用程式執行的環境,包括其安全控制和威脅態勢 雲端託管環境、網際網路
建議措施 減輕已識別風險的建議措施,例如安全控制、測試和監控 實施多重要素驗證、定期進行安全測試和監控應用程式是否有可疑活動

威脅模型(威脅建模)

步驟

  1. 界定範圍與深度
  2. 收集所需資料
  3. 系統建模
  4. 威脅分析
  5. 風險分析
  6. 制定緩解措施
  7. 驗證和更新

Step 1 界定範圍與深度

  • 界定範圍和深度
    • 由於系統規模可能非常龐大
    • 聚焦在系統中最關鍵和最容易受到攻擊的部分
  • 需要識別系統的核心組成部分,例如前端、後端和資料庫
  • 根據專案目標和資源,決定要深入分析哪些部分
    • 例如,如果資源有限,可以先著重在處理個資和帳號密碼相關的功能
  • 確定範圍時,可以思考「哪些資料、功能或元件出事會造成嚴重後果?」
    • 例如法律問題、商譽損失或工程師被開除等
  • 深入分析時,需要根據不同元件的特性,決定分析的深度
    • 例如
      • 對於後端程式碼,可以逐行檢查程式碼和功能
      • 於資料庫,則需關注設定和權限

舉例說明

以下是以處理個資和帳號密碼相關功能為例,說明如何界定範圍與深度:

  • 界定範圍
    • 聚焦關鍵
      • 由於系統規模可能龐大,資源有限的情況下,應先聚焦在處理個資和帳號密碼相關的功能
      • 這些功能出事會造成嚴重後果,例如個資外洩導致法律問題、商譽損失,或帳號密碼管理不當導致系統被入侵,工程師被開除等
    • 核心組成
      • 前端: 使用者註冊、登入頁面、個人資料修改頁面等
      • 後端: 處理使用者資料的 API、帳號密碼驗證邏輯、資料庫存取程式碼等
      • 資料庫: 儲存使用者個資、帳號密碼的資料表,以及相關的資料庫設定和權限
  • 決定深度
    • 前端
      • 檢查前端程式碼是否有將敏感資訊 (例如密碼) 直接顯示在網頁原始碼中
      • 是否有使用 HTTPS 等安全措施保護資料傳輸
    • 後端
      • 逐行檢查後端程式碼,確認是否有進行輸入驗證、帳號密碼加密、安全的資料庫存取等安全措施
      • 例如
        • 檢查是否使用了安全的雜湊演算法 (SHA-256、 bcrypt) 進行密碼雜湊
        • 不使用已知不安全的演算法 (MD5)
        • 檢查是否有實施多因子認證 (MFA) 來加強帳號安全性
    • 資料庫
      • 檢查資料庫設定和權限,確保只有授權人員才能存取敏感資料
      • 確認資料庫是否有定期備份,以及是否有災難復原計畫

Step 2 收集所需資料

  • 目的:深入了解系統的設計和細節,進而找出潛在的攻擊面
  • 方法
    • 收集文件
      • 系統架構圖: 了解系統的整體架構,包含各個元件之間的關係和資料流動
      • 軟體設計文件: 了解系統的設計理念、功能規格、資料庫設計等細節
      • API 文件: 了解系統提供的 API 以及其使用方法,特別是與處理個資和帳號密碼相關的 API
      • 使用者文件: 了解系統的功能和使用方法,從使用者角度思考可能的攻擊面
      • 原始碼: 直接檢視原始碼,了解程式碼的實現細節,找出程式碼中的安全漏洞
      • 第三方函式庫文件: 了解系統使用的第三方函式庫的功能和安全性,評估第三方函式庫帶來的風險
    • 訪談相關人員
      • 前端: 了解前端程式碼的設計和實現,以及前端安全措施的實施情況
      • 後端: 了解後端程式碼的設計和實現,以及後端安全措施的實施情況
      • 資料庫: 了解資料庫的設定和權限管理,以及資料庫安全措施的實施情況
      • 資安: 了解系統整體的安全策略、安全措施和安全事件處理流程
      • 業務: 了解系統的業務需求和安全需求,以及業務流程中可能存在的安全風險
  • 訪談參考
    • 系統使用的技術: 例如作業系統、Web 伺服器、資料庫軟體等
    • 框架: 例如 React、Angular、Vue.js、ASP.NET 等
    • 函式庫: 例如加密函式庫、資料庫連接函式庫等
    • 資料處理方式: 例如資料收集、資料儲存、資料傳輸、資料使用等
    • 加密方法: 例如加密演算法、金鑰管理等
    • 安全設定: 例如防火牆規則、存取控制列表等
    • 測試方法: 例如單元測試、整合測試、系統測試等
    • 防禦措施: 例如入侵偵測系統、入侵防禦系統等
  • 資料收集階段
    • 可以透過開發者角度和攻擊者角度進行
    • 開發者角度:直接檢視程式碼和文件,了解系統架構、程式語言、資料庫軟體等
    • 攻擊者角度:模擬駭客行為,透過瀏覽器和網路封包分析,了解系統架構、作業系統、伺服器軟體等

Step 3 系統建模

  • 目的
    • 系統的組成元件、互動關係和資料流動以圖表形式呈現
    • 方便後續分析
  • 方法
    • 資料流程圖 (DFD)
      • 在於資料的流動和轉換
      • 不關注處理資料的具體步驟
    • 流程圖
      • 流程圖則詳細描述處理資料的邏輯
      • 包含每個步驟的輸入、處理和輸出
  • 除了圖表之外,還需要列出元件之間的通訊方法
    • 例如通訊協定、資料交換方式等

舉例說明

  • 目的: 將系統的組成元件、互動關係和資料流動以圖表形式呈現,方便後續分析
  • 方法:
    • 資料流程圖 (DFD):
      • 用途: 展示資料在系統中如何流動和轉換
      • 重點: 資料的流動方向、資料的轉換過程、資料儲存位置
      • 範例:
        • 使用者在前端註冊頁面輸入個資和帳號密碼
        • 前端將資料傳送給後端 API
        • 後端 API 驗證資料,並將資料加密後儲存至資料庫
    • 流程圖:
      • 用途: 詳細描述處理資料的邏輯
      • 重點: 每個步驟的輸入、處理和輸出
      • 範例:
        • 後端 API 接收前端傳送的使用者註冊資料
        • 驗證使用者名稱是否已存在
        • 使用安全的雜湊演算法對密碼進行雜湊
        • 將使用者資料儲存至資料庫
        • 回傳註冊成功訊息給前端
  • 元件之間的通訊方法: 除了圖表之外,還需要列出元件之間的通訊方法,例如通訊協定、資料交換方式等
    • 範例:
      • 前端與後端 API 之間使用 HTTPS 協定進行通訊
      • 後端 API 與資料庫之間使用資料庫連接函式庫進行通訊

範例圖表

  • DFD 範例
    • dfd
  • 流程圖範例
    • 流程圖

Step 4 威脅分析

  • 目的
    • 是找出系統中可能存在的威脅
    • 包含駭客攻擊、惡意軟體、自然災害等
  • 分析時,需要先識別需要保護的資產
    • 例如個資、付款資訊、系統可用性等
  • 可以利用威脅模型框架
    • 例如 STRIDE,來識別潛在的威脅
  • STRIDE 包含六種威脅類型
    • Spoofing 偽造
    • Tampering 竄改
    • Repudiation 抵賴
    • Information Disclosure 資訊洩露
    • Denial of Service 服務阻斷
    • Elevation of Privilege 權限提升

範例

  • 識別需要保護的資產: 在處理個資和帳號密碼相關功能的案例中,需要保護的資產包含:
    • 個資: 姓名、地址、電話、電子郵件等
    • 帳號密碼: 使用者的帳號和密碼
    • 系統可用性: 確保使用者可以正常註冊、登入和使用系統
資產 STRIDE 威脅類型 案例
個資 (姓名、地址、電話、電子郵件等) 偽造身份 (Spoofing) 攻擊者可能偽造身分,試圖存取他人的個資
竄改資料 (Tampering) 攻擊者可能嘗試竄改使用者個資,例如修改姓名、地址或電話號碼
否認 (Repudiation) 攻擊者可能嘗試否認其行為,例如否認曾經存取或修改個資
資訊洩露 (Information Disclosure) 攻擊者可能嘗試竊取使用者個資,例如透過資料庫漏洞或網路竊聽
阻斷服務 (Denial of Service) 攻擊者可能嘗試發動阻斷服務攻擊,讓使用者無法存取其個資
權限提升 (Elevation of Privilege) 攻擊者可能嘗試利用系統漏洞提升自己的權限,以存取更多個資
資產 STRIDE 威脅類型 案例
帳號密碼 (使用者的帳號和密碼) 偽造身份 (Spoofing) 攻擊者可能偽造身分,嘗試登入其他使用者的帳號
竄改資料 (Tampering) 攻擊者可能嘗試竄改使用者密碼,例如透過密碼重置功能或暴力破解
否認 (Repudiation) 攻擊者可能嘗試否認其行為,例如否認曾經登入系統或修改密碼
資訊洩露 (Information Disclosure) 攻擊者可能嘗試竊取使用者帳號密碼,例如透過網路竊聽或釣魚網站
阻斷服務 (Denial of Service) 攻擊者可能嘗試發動阻斷服務攻擊,讓使用者無法登入系統
權限提升 (Elevation of Privilege) 攻擊者可能嘗試利用系統漏洞提升自己的權限,以取得更多帳號密碼
資產 STRIDE 威脅類型 案例
系統可用性 (確保使用者可以正常註冊、登入和使用系統) 偽造身份 (Spoofing) 攻擊者可能偽造身分,大量註冊假帳號,消耗系統資源
竄改資料 (Tampering) 攻擊者可能嘗試竄改系統設定或資料,影響系統正常運作
否認 (Repudiation) 攻擊者可能嘗試否認其行為,例如否認曾經發動攻擊或造成系統中斷
資訊洩露 (Information Disclosure) 攻擊者可能嘗試竊取系統設定或敏感資訊,以利於後續攻擊
阻斷服務 (Denial of Service) 攻擊者可能嘗試發動阻斷服務攻擊,讓使用者無法正常使用系統功能
權限提升 (Elevation of Privilege) 攻擊者可能嘗試利用系統漏洞提升自己的權限,以控制系統資源或破壞系統

Step 5 風險分析

  • 目的
    • 評估威脅的可能性、影響程度和整體風險等級
  • 常見的風險評估方法包括 DREAD
  • DREAD 包含五個維度
    • Damage Potential 潛在損害
    • Reproducibility 重現性
    • Exploitability 可利用性
    • Affected Users 受影響使用者
    • Discoverability 可發現性
  • 根據每個維度的評分,計算出整體風險等級,並進行排序

範例

每個維度以 1-3 分表示嚴重程度,分數越高代表風險越高

資產 STRIDE 威脅類型 案例 損害 (Damage) 重現性 (Reproducibility) 可利用性 (Exploitability) 受影響使用者 (Affected Users) 可發現性 (Discoverability)
個資 偽造身份 (Spoofing) 攻擊者可能偽造身分,試圖存取他人的個資 3 2 2 2 2
竄改資料 (Tampering) 攻擊者可能嘗試竄改使用者個資,例如修改姓名、地址或電話號碼 3 3 2 2 2
否認 (Repudiation) 攻擊者可能嘗試否認其行為,例如否認曾經存取或修改個資 2 1 2 1 2
資訊洩露 (Information Disclosure) 攻擊者可能嘗試竊取使用者個資,例如透過資料庫漏洞或網路竊聽 3 3 3 3 3
阻斷服務 (Denial of Service) 攻擊者可能嘗試發動阻斷服務攻擊,讓使用者無法存取其個資 2 3 2 3 2
權限提升 (Elevation of Privilege) 攻擊者可能嘗試利用系統漏洞提升自己的權限,以存取更多個資 3 2 3 3 3
資產 STRIDE 威脅類型 案例 損害 (Damage) 重現性 (Reproducibility) 可利用性 (Exploitability) 受影響使用者 (Affected Users) 可發現性 (Discoverability)
帳號密碼 偽造身份 (Spoofing) 攻擊者可能偽造身分,嘗試登入其他使用者的帳號 3 2 2 2 2
竄改資料 (Tampering) 攻擊者可能嘗試竄改使用者密碼,例如透過密碼重置功能或暴力破解 3 3 1 2 1
否認 (Repudiation) 攻擊者可能嘗試否認其行為,例如否認曾經登入系統或修改密碼 2 1 2 1 2
資訊洩露 (Information Disclosure) 攻擊者可能嘗試竊取使用者帳號密碼,例如透過網路竊聽或釣魚網站 3 3 3 3 3
阻斷服務 (Denial of Service) 攻擊者可能嘗試發動阻斷服務攻擊,讓使用者無法登入系統 2 3 2 3 2
權限提升 (Elevation of Privilege) 攻擊者可能嘗試利用系統漏洞提升自己的權限,以取得更多帳號密碼 3 2 3 3 3
資產 STRIDE 威脅類型 案例 損害 (Damage) 重現性 (Reproducibility) 可利用性 (Exploitability) 受影響使用者 (Affected Users) 可發現性 (Discoverability)
系統可用性 偽造身份 (Spoofing) 攻擊者可能偽造身分,大量註冊假帳號,消耗系統資源 2 3 1 3 1
竄改資料 (Tampering) 攻擊者可能嘗試竄改系統設定或資料,影響系統正常運作 3 3 2 3 2
否認 (Repudiation) 攻擊者可能嘗試否認其行為,例如否認曾經發動攻擊或造成系統中斷 1 1 2 1 2
資訊洩露 (Information Disclosure) 攻擊者可能嘗試竊取系統設定或敏感資訊,以利於後續攻擊 3 1 3 1 3
阻斷服務 (Denial of Service) 攻擊者可能嘗試發動阻斷服務攻擊,讓使用者無法正常使用系統功能 3 3 3 3 3
權限提升 (Elevation of Privilege) 攻擊者可能嘗試利用系統漏洞提升自己的權限,以控制系統資源或破壞系統 3 2 3 3 3

Step 6 制定緩解措施

  • 制定緩解措施的目的是針對已識別的威脅,提出相應的解決方案
  • 常見的緩解措施包括
    • 認證(Authentication)
      • 多因子認證 (MFA)
        • 結合多種驗證方法(如密碼、簡訊、指紋、識別證等)來加強存取控制
        • 例如,許多網站登入輸入密碼之後還需要收信箱驗證碼或是手機驗證碼來登入
      • 身分驗證因子
        • 你知道的 (Something you know)
          • 例如
            • 使用者帳號與密碼
            • 個人識別碼 (PIN)
            • 安全問題
            • 圖形密碼
            • 知識型驗證 (如 CAPTCHA 和數學問題)
        • 你擁有的 (Something you have)
          • 例如
            • 智慧卡
            • RFID 卡
            • 磁條卡
            • 智慧型手機
            • 一次性密碼 (OTP)
            • 身分驗證應用程式
            • 硬體 Token
            • USB 安全鑰匙
            • QR Code
            • NFC
            • 藍牙裝置
        • 長在身上 (Something you are)
          • 例如
            • 臉部辨識
            • 指紋辨識
            • 虹膜辨識
            • 聲音辨識
            • 簽名
      • 單一簽入 (SSO)
        • 登入一次即可跨系統存取資源
      • 密碼管理
        • 密碼複雜度: 應設定長度 12 碼以上、足夠複雜且獨特的密碼,避免使用弱密碼
        • 變更預設密碼: 使用預設密碼登入系統時,應於登入後立即變更
    • 授權 (Authorization)
      • 最小特權 (Least Privilege):只給予剛好可以完成其工作職務的最小權限
      • 需要知道 (Need to Know):只有工作職務必要時才給予特定資訊的存取權限
      • 角色為基礎存取控制 (RBAC):根據使用者的角色來分配系統存取權限
    • 加密 (Encryption)
      • 資料加密: 對敏感資料進行加密,確保資料在儲存、傳輸和使用過程中均被妥善加密
      • 加密演算法: 使用安全的加密演算法,例如 AES,並避免使用已知不安全的演算法,如 RC4
      • 雜湊演算法: 使用安全的雜湊演算法,例如 SHA-256、RSA,並避免使用已知不安全的演算法,例如 MD5
    • 輸入驗證 (Input Validation):
      • 驗證所有輸入: 對所有使用者輸入進行驗證,包括檢查資料類型、長度、格式和範圍,確保資料的有效性和安全性
      • 防止注入攻擊: 使用適當的輸入驗證和過濾技術,防止 SQL 注入、跨站腳本 (XSS) 和其他注入攻擊
    • 日誌記錄 (Logging):
      • 記錄所有重要事件: 記錄所有與安全相關的事件,例如登入嘗試、資料存取、系統變更和錯誤訊息
      • 保護日誌檔案: 確保日誌檔案的完整性和機密性,防止未經授權的存取和修改
    • 監控 (Monitoring):
      • 持續監控系統活動: 使用入侵偵測系統 (IDS) 和入侵防禦系統 (IPS) 等工具監控系統活動,偵測可疑行為和已知威脅
      • 定期審查日誌: 定期審查日誌檔案,識別安全事件和趨勢,並採取適當的措施
      • 安全資訊與事件管理 (SIEM): 使用 SIEM 系統收集、分析和關聯來自不同來源的安全日誌,以便更有效地偵測和回應安全威脅
  • 在制定緩解措施時,需考量自身資源和能力,確保措施可行
  • 可以參考相關安全標準、規範和最佳實務
  • 以下列出一些常見威脅的緩解措施範例
    • 帳號盜用:密碼策略、雙重驗證、帳號監控
    • 信用卡資訊竊取:符合信用卡安全標準、確保資料儲存、處理和傳輸安全
    • DDoS 攻擊:彈性架構、快取技術、負載平衡、DDoS 防護服務
    • 資料庫資訊竊取:輸入驗證、參數化查詢、最小權限、資料庫安全設定

範例

  • 偽造身份
    • 多因子認證 (MFA):要求使用者提供多種驗證因子,例如密碼和簡訊驗證碼,才能登入
    • 生物辨識:使用指紋辨識或臉部辨識等生物辨識技術來驗證使用者身份
  • 竄改資料
    • 資料加密:對儲存和傳輸中的資料進行加密,防止未經授權的修改
    • 數位簽章:使用數位簽章來確保資料的完整性和來源
    • 資料驗證:對使用者輸入進行驗證,確保資料的有效性和安全性
  • 否認
    • 日誌記錄:記錄所有交易和使用者活動,以便追蹤和審計
  • 資訊揭露
    • 資料加密:對儲存和傳輸中的資料進行加密,防止未經授權的存取
    • 存取控制:實施嚴格的存取控制策略,只允許授權使用者存取敏感資訊
  • 阻斷服務
    • 入侵偵測和防禦系統 (IDS/IPS):使用 IDS/IPS 來偵測和阻止 DDoS 攻擊
    • 負載平衡:使用負載平衡技術來分散流量,避免單一伺服器過載
  • 特權提升
    • 最小特權:只給予使用者執行其工作職務所需的最小權限
    • 定期審查權限:定期審查使用者權限,確保沒有不必要的權限

Step 7 驗證和更新

  • 威脅模型需要定期審查和更新,以確保其有效性
  • 驗證方法包括
    • 滲透測試 (Penetration Testing)
    • 漏洞掃描 (Vulnerability Scanning)
    • 程式碼審查 (Code Review)
    • 資安顧問諮詢
  • 更新時機
    • 定期審查
    • 發生重大資安事件
    • 系統架構或功能發生變更

工具和資源

  • Draw.io:繪製 DFD 和流程圖
  • 微軟威脅模型工具:內建 STRIDE 框架和威脅屬性
  • OWASP:提供威脅清單、確認表和安全指引
  • ThreatModeler:基於 OWASP 框架的威脅建模工具
  • SpiderFoot:網站爬蟲工具,可協助了解網站架構

其他資源

  • 可以參考 MITRE ATT&CK 框架 來擴展攻擊思路和情境
  • 可以利用 攻擊樹 (Attack Tree) 來分析攻擊者的目標和攻擊路徑
  • 可以透過 AI 輔助 來提升威脅建模效率,例如自動化產生報告、分析攻擊路徑等

上一篇
資安這條路:Day 26 SSDLC 安全開發軟體生命週期─概述、需求階段
下一篇
資安這條路:Day 28 SSDLC 安全開發軟體生命週期─開發階段與 OWASP 標準(OWASP Top 10、OWASP ASVS、OWASP Developer Guide)
系列文
資安這條路:系統化學習網站安全與網站滲透測試30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言